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System a nd method for searching, finding and contacting dates on the 
Internet in instant messaging netyyorks and/or in other methods that 
enable immediate finding and creating immediate contact. 

Request for making small corrections and clarifications. 

I am hereby submitting a request for a few small corrections and 
clarifications in the enclosed patent request. The changes are all marked 
with underline. (The claims in the submitted patent have been changed in 
order to fit the limitations of claims in the USA, so changes in the claims 
are not included here). 



1. I would like to make the following underlined corrections/clarifications 
in the 1'* paragraph of the Definitions and clarification section: 

Through out the patent whenever_variations or yarious solutions are mentioned, 
it is also possible to use yarious combinations of these yariations or of elements in 
them, and when co mbinations are used, it is also possible to use at least some 
elements i n them separately or in other combinations. These yariations can be in 
different embodiments, or different yersion of the software, or sometimes 
different options available to choose from. In other words: certain features of the 
inyention. which are described in the context of separate embodiments, may also 
be provided in co mbination in a single embodiment. Conversely, various features 
of the invention, whic h are described in the context of a single embodiment, may 
also be provided separately or in any suitable sub-combination. 

2. 1 would like to make the following underlined correction/clarification in 
the definition of "User" within the Definitions and clarification section: 

"User" or "users" as used throughout the patent, including the claims, can 
interchangeably to be either user or users, and can refer to both sexes even when 
words such as "he" or "she" or "his" or "her" are used. 

3. I would like to make the following underlined corrections/clarifications 
in the shown part of the reference to Fig. la: 

Fig. la shows a preferable structure of the client-server system in the IM network, 
with the part that implements the dating. The instant messaging client (2) runs within 
the user's computer (1), and, if it's not a custom-made client, is preferably coupled to 
a plug-in or plug-ins or add-on or add-ons (3) for adding the special features of the 
present invention, otherwise the parts that implement these features in the client are 
part of the client itself The user's computer (1) is connected through connection (4) 
to the Internet (5), where our server(s) (6) (with dynamic or static database(s) or both 
(7)) reside. The database (no matter if dynamic or static) is of course preferably run 
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by the server, and all date searches are preferably carried out there, although there can 
be for example a separation between the server (or servers) that handles the IM 
activity, and another server (or servers) that run the actual dating database and 
perform the searches and compatibility matches, etc., and return the results to the 
requesting client programs. 

Preferably the system also has at least one or more of the following improvements 
over existing Instant Messaging systems: 

1 . The contactee list is preferably run by the client program (2) in the customary 
shape of a table, but preferably indicates also near each contactee additional 
data such as for example the last date & time he/she was online (in the instant 
messaging network) and/or the most common range of hours and/or week days 
he/she is most likely to be found online (In another variation this can be a more 
crude time range, such as for example, morning, noon, afternoon, early 
evening, late evening, and night), and/or for example the last time he/she 
performed a search for potential dates in the system (preferably the client 
program automatically gets these updates from the server when the user is 
Online), and/or geographical area (or for example some relative distance 
estimate compared to the user), and/or the compatibility scores, and/or how 
often they are usually online (such as for example how many hours on average 
per week or per day). This is very important since many times, and especially 
if the user has not used the system for some time, it is very hard to tell which 
of your contactees are still available and when it is likely to encounter them. 
Preferably near each contactee is listed also the last time contact was made 
with him/her and/or for example the length of his/her history list. Preferably, 
the table of contactees contains also a visible status indication about each 
person - for example if he/she is still looking for romance or other types of 
connection, etc. Preferably these additional data fields are visible by default 
near each contactee without having to click on anything in order to see them. 
An example of a way the contactee list can look like is shown in Fig. 8. 

2. Preferably the user can choose if to sort the contactee list according to 
alphabetic order, compatibility score (at least for those contactees that were 
added through the date-searching), or any of the other data mentioned in clause 
1 above or additional data , or any combinations of these. 

3. Preferably the user has the ability to know how many people have him/her in 
their contactee lists. This is very easy to accomplish since either the user's 
client program or the server or both can for example increase a counter or 
decrease it whenever someone adds or deletes the user. Another possible 
variation is that the client program or the server or both can also keep a list of 
all the people that added the user to their contactee lists, so that the user can for 
example send messages that can be automatically distributed to all of them, 
and/or request to view the list of people that have him/her on their lists 
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(preferably at least their names and e-mails and/or IM ids). So preferably the 
server and/or the client program keep for each user also a "reverse" contactee- 
list, which lists all the other users who added him/her to their list and haven't 
deleted him/her yet. Another possible variation is that the seiTer keeps only a 
copy of each contactee list and when needed the server runs over these lists and 
searches them, preferably with the aid of an index. {Of course, if the act of 
adding someone to the list of contactees is reciprocal, then the client program 
can know automatically that you were also added to their list, but this is not 
necessarily so, especially in cases that the person has not limited adding him to 
the list to requesting explicit authorization. Also, even if the adding to the 
contactee list could in some systems be automatically reciprocal, there is no 
reason why the deletion should be like this: if person A deletes person B from 
his list, it does not necessarily mean that person B wants to delete person A 
from his list, so the deletion process would make it non-trivial to know on 
which or on how many contactee lists you are actually listed}. 

4. Preferably, if someone changes his/her status for example from "available for 
dating" to non-available, etc., this is automatically broadcast (for example by 
the client program of that user or by the server) to all the people who have 
him/her on their contactee list, so that his/her status is updated on their lists 
(This can be done for example by an automatic message directly from that 
user's client program that updates the client programs of these people when 
they are Online and if they are Offline waits for them till they are Online again, 
or for example done similarly through the server). This updating is of course 
preferably in addition to making the person not appear in further date searches 
by others if the change in status implied this (until the status allows this again) 
- for example if he/she is in a relationship, etc. 

5. Preferably when the matching potential dates are found, they are listed by 
descending reciprocal compatibility score. However, since there can be a large 
variance between the way people mark the acceptable ranges in the "Wanted" 
in each question and the way they mark the importances of questions, the score 
of how much someone fits the user's expectations can depend very much on 
the general bias of the user, in other words his/her tendency to be more or less 
"generous" in general in his/her scores. Therefore, in order to create a certain 
minimum nomialization, preferably for sorting by reciprocal score, the score of 
how much the potential date fits the user's expectations is preferably given 
stronger weight (and thus effects more the reciprocal score, which is a 
weighted average) than how much the user fits the potential date's 
expectations. Another possible variation is to create some normalization of this 
by taking into account for example the average 1-way score that the user gives 
compatible dates and his standard deviation, and thus either use normalized 
scores, or use the normalization to create only a partial correction of the 
absolute scores. This is more preferable than frill normalization because the 
fact that someone gives generally higher scores to everyone can also mean that 
he/she is really more open and more fit for many people than someone who 
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gives lower scores in general. This can have the effect of automatically also 
reducing the number of times such a person appears on other users' lists, in 
order to improve the balance. Another possible variation is for example to 
automatically limit at least temporarily the number of times the user can appear 
on other users' lists if his/her number of appearances in other lists has gone 
beyond a certain excess limit defined by the program (preferably in terms of 
percentages, since the absolute numbers change as the database grows). In 
addition to this, preferably if a user's compatibility scores are generally low 
beyond a certain criterion, preferably the system can report to the user (for 
example automatically or upon the user's request after displaying this option) 
the list of questions that most contributed to the problem (for example the 10 
questions that most lower his scores with other people, or all the questions that 
contributed more than a certain factor to lowering the scores). This can be done 
for example by letting the matching program that runs on the server keep 
statistics for each user while running him/her against the potential dates, so that 
the statistics track the questions that are most problematic. Another possible 
variation is to run this statistical check only upon request and/or only on a 
subset sample of potential dates in order not to slow down the normal matching 
process when running the search on all potential dates. Another possible 
variation is for example to give the user also the option of choosing sorting by 
1-way compatibility scores, and in that case preferably the user will get 
someone only if the opposite 1-way compatibility score is above a certain 
minimum, preferably a minimum set by the system and not by the user. (In 
other words you can request a sorting by how much the mate fits your 
expectations, but you will only be allowed to get mates whose expectations 
you also fit to a certain minimum). Preferably in this case the search results list 
shows also the reverse compatibility for each date. Of course these options can 
be used also in normal computer-dating systems. As mentioned above, 
preferably the user has also the option to request just a search by a list of traits' 
which is in other words a 1-way compatibility but typically on a small number 
of traits and without necessarily checking the opposite 1-way score, but in this 
case preferably the system can for example create various limitations such as 
for example that persons who don't fill the questionnaire completely (or at 
least a minimal subset of required questions) cannot participate at all in 
searches by others, etc., or for example not giving the person's phone, etc., in 
order to reduce the chance for harassment if the search ignores the reverse 
compatibility'. So if the questionnaire has for example about 150 questions, the 
users can have a very systematic and serious compatibility search, but also 
experiment with instant searches especially when first trying out the system, by 
filling just the Wanted and the Importance in the few questions that most 
interest him/her, and thus start getting results already from the first minutes. So 
for example within minutes after entering the system for the first time, the user 
can search for example for all the blondes with high IQ and a big bust that are 
either currently online or not. Allowing such huge flexibility is very important 
because each persons can want very different things so a very large number of 
questions to choose from is preferably given to the user, eventhough the user 
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might choose for example just 3-10 questions to start with, but these are the 
few questions most important to him/her. (When choosing this option after the 
user has already filled the full questionnaire, preferably these requested traits 
are used instead of his preferences as marked for the fall questionnaire, and his 
self data from the questionnaire can preferably either be taken into 
consideration or not, or taken into consideration at least partially, depending on 
the type of search or other consideartions). Another possible variation is to 
allow any two users of the system to check the exact compatibility between 
them, for example by entering their two unique Id numbers and thus get normal 
compatibility scores or for example an even more detailed analysis. Of course, 
various combinations of the above variations are also possible. 

6. Preferably, if the user requested a search also on people who are not currently 
Online, those that are Online appear in the list of results with a preferably 
easily visible mark, such as for example a different color indication and/or text 
size and/or shape and/or special icon, or for example two or more separate lists 
are generated (or one list divided into two or more parts), one with people 
currently online and one or more with people not currently online. Within each 
list or part of the list preferably the resuhs are still ordered by descending 
compatibility score. Preferably near each person in the list of people not 
currently online there is also additional data such as when they were last online 
and/or how often they are usually online (such as for example how many hours 
on average per week or per day). Another possible variation is that the list of 
people who are not currently online can be fiirther divided for example into 
smaller parts, so that for example people who were online in the last week 
appear in a section before people who haven't been online for example for 
more than a month, etc. Within each section preferably the sorting is again 
based on descending, preferably reciprocal, compatibility score. Preferably the 
size of each section can be determined automatically for example both by the 
compatibilit>' score and by the recency. Another possible variation is that there 
are no separate sections according to recency, but the compatibility score itself 
and/or the sorting takes into account to a certain degree also the recency, for 
example according to a weight assigned for the recency factor, determined 
either by the user or by the system or both. Of course various combinations of 
these and other options are also possible. Of course many of the options 
mentioned here and in other clauses can also be used in normal computer- 
dating systems. An example of the way the results can look like is shown in 
Fig. 9. 

7. Preferably the client program can receive automatic updates fi-om the server, so 
that for example if questions (or options within questions) were added or 
deleted or changed in the compatibility questionnaire, it will be updated when 
the user is online with the client program. This is important, since unlike 
normal dating services on the Internet, where the questionnaire is typically on 
the server, in this case, for efficiency the questionnaire can be in the client 
itself, which also enables filling or correcting the questionnaire also when you 
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are offline. Another possible variation is that the client program retrieves again 
a new updated copy of the questionnaire when the user goes online. Preferably 
the client program can also be itself updated automatically when needed, for 
example by sending automatically new modules to all the users in the IM 
network. This feature if it had existed in advance could for example be used to 
add the dating option to all the ICQ users in the world almost instantly (or for 
example to add additional features to it later), without waiting for them to go 
and download a new version of the client program. This is very important, 
since even if users are informed about a great set of new features, it typically 
takes a long time till they go and actually download it, and the lag in updating 
causes incompatibilities between users who have already downloaded the new 
version and users that didn't. It is also much more efficient in terms of 
bandwidth. (However, for reasons of security, when this automatic update 
occurs, preferably the user is informed about it by the system and asked for 
confirmation). 

8. Preferably, If the user is accessing the system from a client program on a 
different computer then preferably after giving an Id and password, the client 
program can get his/her questionnaire data and a copy of his/her contactee list 
from the server, so he/she can still work normally in the instant messaging 
network. However, this means that a copy of each user's contactee list is 
preferably kept also on the server. 

9. Many of these concepts can also be similarly implemented also in cellular 
phone networks, and especially in networks where the phones are constantly 
connected and there is high bandwidth, such as for example in the 3G (S'"'* 
Generation) cellular networks. In such networks, in addition to the normal 
ability to send the person an e-mail or an instant message, preferably the user 
can also generate for example an SMS message, or generate a phone-call right 
from the instant-messaging client. However, (both with cellular and non- 
cellular phones) in case some people don't like to give their phone in the 
questionnaire for example for fear of harassment, preferably the system applies 
an optional "phone proxy" or "phone escrew service", which means that the 
user has an option to mark his/her phone as protected, and when someone gets 
his/her phone on the list, that someone can call the user for example through a 
special visible code but the code does not contain the real number and the call 
has to go through the proxy. The call itself can be done for example by direct 
activation though the client program (if it is done for example from a cellular 
phone connected to the Internet, or from a computer with a microphone and 
sound card), or for example through phoning a special number and then 
clicking the code, and the server there automatically routes the call to the real 
number. This way various protections can be implemented, such as for 
example allowing only a few first calls through the code and if the caller does 
not get from the user his/her real phone number by then, he/she can no longer 
use the code, thus automatically preventing harassments. The code can also be 
for example uniquely generated for each person who conducted the search, so 
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that the code cannot be used by someone else. Also, since the code can 
preferably be changed very easily, the user can preferably also request to 
change it immediately if harassed by someone, so that someone can't use it 
anymore even if the use limit hasn't been reached yet. Preferably this can also 
be used for example to enforce normal calling times and/or preferred calling 
times specified by the user, so the system preferably uses the information about 
country from the questionnaire and/or the time data from the system on each 
user's computer or cellular phone, and using an updated table of time zones, 
preferably when someone is calling through the code, the system makes sure 
that the call will not be for example in the night hours of the person being 
called. Another possible variation is that even without a code, simply clicking 
for example on a phoning option near the displayed date can immediately 
connect the user to that person without disclosing at this stage the number 
itself. This has the further advantage that this clicking option is available only 
to the user, so there is no code that can be transferred to others. Of course, such 
a "Phone proxy" system can be used also in other Online computer dating 
services that want to allow the user to get a list of dates which can all be 
reached immediately by phone, so those that don't want to give the phone can 
use the "protected phone" option. Of course, various combinations of the 
above variations are also possible. 

10. Another problem in such constantly connected cellular networks, and also for 
example in other constant Internet connections, such as through cable TV 
companies or through ADSL, a new definition is needed about what it means 
to be "online", otherwise everyone on those networks can be defined as being 
online all the time (especially if the Instant messaging client is configured to 
connect automatically when starting an Internet connection). Therefore, at least 
in such networks preferably the user is considered to be online for example 
only if he has initiated or responded to any action related to the Instant 
messaging client for example in the last hour (or any other reasonable time) 
and is considered to be off-line for example if he hasn't typed anything on the 
computer for a certain time, etc. This means of course that the static and/or 
dynamic database is updated also according to these activity rules and not only 
when a user activates or deactivates the client or the connection. Another 
possible variation is to use these or similar rules also in any type of connection, 
as explained also in the definition of "Online" in the definition section. 

11. In cellular networks preferably the system contains also additional features, 
such as being able to get a special indication if someone is very near to the 
user, for example within a certain radius. This can be accomplished for 
example by using info from the cellular company's cells ,and/ or by using this 
info directly from the phones, for example when they become GPS enabled. 
This way the user can know for example that some compatible date is very 
close to him/her (for example by a special mark in his list of search results 
and/or in his contactee list). Another possible variation is for example that if 
the user sees someone that he/she likes and both have cellular phones and are 
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members of the system, then preferably a certain optical or wireless signal 
generated by the phones themselves can tell the user through the status if the 
person next to him/her is available, and preferably the two phones can 
exchange Id's or numbers automatically and/or the questionnaire data directly 
and thus the client program can immediately run a check (preferably through 
the server) to see how compatible the two persons are. Preferably this is done 
by a short range wireless technology, such as Bluetooth, since Bluetooth 
technology will probably be standard on most cellular phones within the next 
few years, but it can also be any other short range wireless technology that is 
used or will be used in the future, such as for example UWB, which can easily 
compete with Bluetooth. Another possible variation is that the client program 
on each or at least on one of the phones/cellular devices can run the matching 
between the user and the potential dates in the immediate area without the need 
to access the server for this, for example by running a local, preferably limited 
version of the matching program and preferablv limiting the check to the one 
or more relevant persons around. Therefore, this feature can be used also 
independently of the IM network and/or of the online dating service, for 
i ?1 example by simply letting cellular phones that are close to each other and are 

marked by their user with the status "available for dating" - exchange data and 
check automatically compatibility and alert the user anytime he/she is close to 
someone available for dating and compatible. A more limited implementation 
of this that does not even need a real matching program is for example to use 
this method just to let the user know that someone next to him/her is available 
for dating, or use it for example with a minimum amount of data, such as for 
' ^ example age, sex, education, etc. If the match is sufficient, then preferably for 

: example the user or each of the matching persons gets at least a few minimal 

I details about the other person's appearance (such as for example Appearance, 

Height, Body build. Hair length. Hair color. Hair shape, etc., and/or a picture, 
if available, or "approximate image" if available, as explained below in clause 
16, if no real picture is available) in order to be able to try and match this with 
what he/she sees around, and the other person's phone number (or "proxy 
number", as explained above, and/or an option to click for example on a phone 
icon near the date's data and be connected immediately), and/or be able to 
enter for example immediate textual chat with the other person. This can be 
useful for example at a university, on a bus, on a train, in shopping malls, etc. 
Another possible variation is that the cellular phones (or for example palm or 
other relevant cellular or wireless devices, as explained in the definitions) are 
able to exchange various queries between them. For example each user can 
mark that out of the large number of questions to choose from there are for 
example 5 questions which he/she would like to know in advance: for example, 
apart from is the other person available for dating, what is his/her level of 
education, what is his/her main area of work or study, etc. Preferably the user 
can also send the query with additional specifications in order to increase the 
chance that the reply will come from the right person. For example in a bus or 
train or university cafeteria or library there can be dozens or even hundreds of 
people within range. So if for example it is a blonde girl that looks a certain 
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age, preferably the user can ask for example that only the devices of blonde 
girls that are available for dating and within a certain age limits reply. The 
query is then preferably transmitted by the bluetooth (or other short range 
communication) to all the devices in the vicinity that are in range, and each 
device checks if its user is marked available for dating, and then if he/she fits 
the definitions, before broadcasting the reply to the question described above 
(such as is the person available, what is his/her education, what is his/her field 
of study or work, etc.). Preferably there is a different answer if the person is 
not available than if he/she is not a member of the system, otherwise a lack of 
reply could mean ambiguously both of these possibilities. Another possible 
variation is that the phone (or a preferably small and non-conspicuous add-on 
coupled to the phone) enables the user to point his/her device directly at the 
direction of the person that caught his/her eye, which preferably transmits 
some Id code and/or the phone number of the user who points it, and 
preferably sensors on that device of the person that was pointed to can find out 
that someone pointed the device and reply to the quer> directly with its own Id 
and/or phone number, etc. This pointing device can be based for example on 
infrared or on a directional short range wireless antenna. (This can work also 
on other devices even without the cellular network, such as for example palm 
devices that are bluetooth enabled even if they are not connected to the cellular 
network, or special gadgets for dating). However this is less desirable, since 
most people will be embarrassed to buy a special device for that and/or 
embarrassed to be seen pointing the phone at someone. Another possible 
variation is to implement it on the level of cells or groups of cells, so that the 
cellular phones know that they are close to each other for example by getting 
the information fi-om the cellular company's cells. Another possible variation 
is to run the matching normally, but when dates are found that according to the 
info from the cells and/or for example from the GPS and/or for example from 
the bluetooth indication (or other short range communication technology) are 
also very close to the user, these dates are preferably for example marked with 
a special conspicuous sign (for example in the search results list and/or or in 
the contactee list) and/or moved to a special category on top of the list of date 
search results and/or in the contactee list, or their score for match on area in 
increased by a certain factor and simply incorporated in the total compatibility 
score. In this version, preferably dates that are close for example by blutooth 
indication are given even a more emphasized mark or moved higher to the top 
than dates who are only close by info from the cells. Since for some users the 
level of compatibility is much more important as long as the date is still within 
a reasonable area, while for others the fact that someone is now very close to 
them might be more important, preferably the user can easily experiment with 
increasing and reducing the weight given to the immediate vicinity factor. 
Also, for example people looking for pen-pals will probably put much less 
weight on the area. Another possible variation is that the system allows the 
user also to request separate search resuhs lists (and/or contactee lists) 
according to area or marking for closer people - also more generally, such as 
for example putting all the people from the same country or state or town in a 
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separate category. Another possible variation is that if the server or servers 
become for example too overloaded because of too many users using the 
system, preferably different servers are used for different areas and date 
searches are for example limited in the size of areas that can be requested. Of 
course, various combinations of the above variations are also possible. 

12. Preferably if someone hasn't entered the system for a certain time period, such 
as a for example a few months (and/or if someone else fills a for example a 
"freeze form" or some other form of report about that person, reporting that the 
person said that it is no longer relevant), the server can preferably generate an 
automatic message to him/her (for example through e-mail or instant message) 
to ask for example if he/she is still interested in compatible dates, and if the 
person confirms this, or if no reply comes back for example after a certain 
period or preferably after sending more reminders, the person is preferably 
automatically "frozen" (so that people no longer receive him/her in the 
searches) until there is another indication (for example if he/she enters the 
system, or performs a new search, or updates the data, etc.). Preferably, the 
freeze form contains also the reason (such as for example the person found 
someone through the service, found someone elsewhere, found someone 
trough the service and got married, found someone not trough the service and 
got married, etc.). Another possible variation is that the system ignores the 
"freeze form" (that was filled by someone else) if the user has been active very 
recently or is currently Online, and especially if he/she performed a date- 
related activity such as conducting a date-search recently. Another possible 
variation is that the system does not ignore the freeze form if the reason is 
more significant, such as for example the person got married according to the 
report. By using this feature the weight given to the recency data can be 
significantly reduced since this can significantly decrease the chance that the 
potential dates found will be no longer relevant, even if their data is older. 

4. 1 would like to make the following underlined correction/clarification in 
the reference to Fig. 3: 

Fig. 3 shows a preferable way in which the dynamic database of users that are 
currently Online works. As soon as the user opens the Internet connection and 

activates the instant messaging client (which is either our own client program or the 
client program of one of the common instant messaging networks with our custom- 
made plug-in or plug-ins or add-on or add-ons), preferably a message is sent to the 
dynamic database server(s) containing the user's filled compatibility questionnaire 
data (31). Then our client or the plug-in or add-on coupled to the client keeps sending 
at short intervals a short message to one of our servers containing the user's unique id 
so that the system can tell if the user is still logged-in (preferably these short messages 
are sent either to the Database server itself or to another server, which will in turn 
notify the database server if the messages stop coming) (32). (of course, if it is a plug- 
in or add-on to an existing client program, it is also possible to get such info bv letting 
our server query the normal server of the client, but that is less efficient and might be 
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for example blocked by the normal server of the client). When the user requests an 
instant dating search (For example with his profile in a 2-way compatibility search or 
as a 1-way search or search for a small group of qualities, for example - find all the 
blondes with highest IQ who are currently logged in, or find them for example only if 
the reciprocal compatibility score with them is above a certain percent; Other search 
options can be for to example find only dates with a minimum compatibility score 
requested by the user, but preferably the user cannot request a minimal score lower 
than a certain minimum required by the system as the minimal acceptable 
compatibility score), the client sends the appropriate request to the dynamic database 

(33) . The dynamic database will make the search accordingly and send back the list of 
most compatible dates that are currently connected, preferably including various 
details about them according to the type of search. The user may also add any of them 
to his/her contactee list and can be notified immediately when they are Online again 

(34) in a similar way to the description of 44. When the short messages firom the 
client cease reaching the appropriate server, indicating that the user is no longer 
connected, his data is removed from the dynamic database (35). 

5. If possible I would like to make the following underlined corrections/ 
additions in clauses 11,15,16 & 18 of the reference to Fig. la, with the 
understanding that these specific additions will be given a later priority 
date: 

11. In cellular networks preferably the system contains also additional features, 
such as being able to get a special indication if someone is very near to the 
user, for example within a certain radius. This can be accomplished for 
example by using info from the cellular company's cells, and/or by using this 
info directly from the phones, for example when they become GPS enabled. 
This way the user can know for example that some compatible date is very 
close to him/her (for example by a special mark in his list of search results 
and/or in his contactee list). Another possible variation is for example that if 
the user sees someone that he/she likes and both have cellular phones and are 
members of the system, then preferably a certain optical or wireless signal 
generated by the phones themselves can tell the user through the status if the 
person next to him/her is available, and preferably the two phones can 
exchange Id's or numbers automatically and/or the questionnaire data directly 
and thus the client program can immediately run a check (preferably through 
the server) to see how compatible the two persons are. Preferably this is done 
by a short range wireless technology, such as Bluetooth, since Bluetooth 
technology will probably be standard on most cellular phones within the next 
few years, but it can also be any other short range wireless technology that is 
used or will be used in the future, such as for example UWB, which can easily 
compete with Bluetooth. Another possible variation is that the client program 
on each or at least on one of the phones/cellular devices can run the matching 
between the user and the potential dates in the immediate area without the need 
to access the server for this, for example by running a local, preferably limited 
version of the matching program and preferably limiting the check to the one 



20/02/02 Yaron Mayer 



12/17 



or more relevant persons around. Therefore, this feature can be used also 
independently of the IM network and/or of the online dating service, for 
example by simply letting cellular phones that are close to each other and are 
marked by their user with the status "available for dating" - exchange data and 
check automatically compatibility and alert the user anytime he/she is close to 
someone available for dating and compatible. A more limited implementation 
of this that does not even need a real matching program is for example to use 
this method just to let the user know that someone next to him/her is available 
for dating, or use it for example with a minimum amount of data, such as for 
example age, sex, education, etc. If the match is sufficient, then preferably for 
example the user or each of the matching persons gets at least a few minimal 
details about the other person's appearance (such as for example Appearance, 
Height, Body build, Hair length. Hair color. Hair shape, etc., and/or a picture, 
if available, or "approximate image" if available, as explained below in clause 
16, if no real picture is available) in order to be able to try and match this with 
what he/she sees around, and the other person's phone number (or "proxy 
number", as explained above, and/or an option to click for example on a phone 
icon near the date's data and be connected immediately), and/or be able to 
enter for example immediate textual chat with the other person. This can be 
useful for example at a university, on a bus, on a train, in shopping malls, etc. 
Another possible variation is that the phone (or other mobile device) can use 
for example the GPS of its own position and the position of the potential date 
and use for example its own north-west or compass direction, in order to point 
to the user the direction and distance to the potential date that was found, or for 
example use also geographical information such as for example a street map 
(obtainable for example from the nearby cells), in order to let the user know 
more exactly the location of the potential date. Another possible variation is 
that the cellular phones (or for example palm or other relevant cellular or 
wireless devices, as explained in the definitions) are able to exchange various 
queries between them. For example each user can mark that out of the large 
number of questions to choose from there are for example 5 questions which 
he/she would like to know in advance: for example, apart from is the other 
person available for datmg, what is his/her level of education, what is his/her 
main area of work or study, etc. Preferably the user can also send the query 
with additional specifications in order to increase the chance that the reply will 
come from the right person. For example in a bus or train or university 
cafeteria or library there can be dozens or even hundreds of people within 
range. So if for example it is a blonde girl that looks a certain age, preferably 
the user can ask for example that only the devices of blonde girls that are 
available for dating and within a certain age limits reply. The query is then 
preferably fransmitted by the bluetooth (or other short range communication) 
to all the devices in the vicinity that are in range, and each device checks if its 
user is marked available for dating, and then if he/she fits the definitions, 
before broadcasting the reply to the question described above (such as is the 
person available, what is his/her education, what is his/her field of study or 
work, etc.). Preferably there is a different answer if the person is not available 
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than if he/she is not a member of the system, otherwise a lack of reply could 
mean ambiguously both of these possibilities. Another possible variation is that 
the phone (or a preferably small and non-conspicuous add-on coupled to the 
phone) enables the user to point his/her device directly at the direction of the 
person that caught his/her eye, which preferably transmits some Id code and/or 
the phone number of the user who points it, and preferably sensors on that 
device of the person that was pointed to can find out that someone pointed the 
device and reply to the query directly with its own Id and/or phone number, 
etc. This pointing device can be based for example on infrared or on a 
directional short range wireless antenna. (This can work also on other devices 
even without the cellular network, such as for example palm devices that are 
bluetooth enabled even if they are not connected to the cellular network, or 
special gadgets for dating). However this is less desirable, since most people 
will be embarrassed to buy a special device for that and/or embarrassed to be 
seen pointing the phone at someone. Another possible variation is to 
implement it on the level of cells or groups of cells, so that the cellular phones 
know that they are close to each other for example by getting the information 
from the cellular company's cells. Another possible variation is to run the 
matching normally, but when dates are found that according to the info from 
the cells and/or for example from the GPS and/or for example from the 
bluetooth indication (or other short range communication technology) are also 
very close to the user, these dates are preferably for example marked with a 
special conspicuous sign (for example in the search results list and/or or in the 
contactee list) and/or moved to a special category on top of the list of date 
search results and/or in the contactee list, or their score for match on area in 
increased by a certain factor and simply incorporated in the total compatibility 
score. In this version, preferably dates that are close for example by blutooth 
indication are given even a more emphasized mark or moved higher to the top 
than dates who are only close by info from the cells. Since for some users the 
level of compatibility is much more important as long as the date is still within 
a reasonable area, while for others the fact that someone is now very close to 
them might be more important, preferably the user can easily experiment with 
increasing and reducing the weight given to the immediate vicinity factor. 
Also, for example people looking for pen-pals will probably put much less 
weight on the area. Another possible variation is that the system allows the 
user also to request separate search results lists (and/or contactee lists) 
according to area or marking for closer people - also more generally, such as 
for example putting all the people from the same country or state or town in a 
separate category. Another possible variation is that if the server or servers 
become for example too overloaded because of too many users using the 
system, preferably different servers are used for different areas and date 
searches are for example limited in the size of areas that can be requested. Of 
course, various combinations of the above variations are also possible. 

15. Preferably the user can also request from the system to notify him/her 
automatically whenever there is a new potential date that entered title system 
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and has a higher compatibility with him/her than a certain criterion (such as for 
example higher than the lowest compatibility score in his/her current contactee 
list, or higher than an absolute minimal score defmed by the user), or fulfills a 
certain condition, for example, all blondes with big bust and high IQ. Another 
possible variation is that this is done for example automatically by default 
unless the user requests otherwise. This is better than the state of the art, where 
the user gets a list only at certain times (such as for example once a month or, 
when he/she himself initiates a search). This can be applied for example when 
the new person submits his/her data for the first time to the system or performs 
a compatibility search for the first time, and preferably the user can ask either 
to be notified for example whenever such a new person exists in the static 
database, (if there is a static database), or only when that user is also Online 
(Of course when submitting the questionnaire or performing the search the new 
person is by definition Online, but the user that wished to be notified might be 
for example offline at that time and when he/she comes back Online the new 
person might be offline already). This can be done for example by keeping 
pending search requests (preferably only one search-request or up to a few 
pending search requests permitted per person) and/or keeping the minimum 
criterion for that person on his/her record on the server (for example the lowest 
score on the list that he/she got so far and/or the lowest score on his contactee 
list so far), and for example when the new person sends his/her data for the 
first time or requests a search or changes the data (but for efficiency reason 
most preferably this is done only or mainly when the new user requests a 
search), a reciprocal search is performed on all the potential mates in the 
system, and while checking the new person's data against each relevant 
potential mate in the system, the server preferably also checks if a condition 
has been fulfilled that requires sending the appropriate notification or update to 
the person against which the new person's data is being checked. This may 
sound a bit inefficient but preferably it has only a relatively small effect on the 
search speed, since various optimizations can be performed anyway such as for 
example stopping the comparison with a given person immediately for 
example if the area doesn't fit or the age doesn't fit. Preferably the user can 
also choose for example if he/she wants to be notified by an e-mail and/or 
instant message and/or by automatically having the new persons be inserted 
into his/her list of contactees (This choice can be made for example in general, 
or depending on the case, so that for example the user requests that someone be 
added automatically into his/her contactee list only in cases of especially high 
matching). Preferably the new person also has the choice in advance if he/she 
wants to be inserted automatically into the contactee lists of relevant people or 
at least for example into the contactee lists of the persons on top of his/her list 
of date-search results. This saves a lot of time and increases the chance for 
instant connection, especially if the new person prefers for example that the 
other dates contact him/her (females for example tend more than males to 
prefer to wait for someone to contact them). When the user is a member 
through cellular phone and not currently Online, another possible variation is 
to notify the user also for example preferably by sending an automatic ring 



20/02/02 Yaron Mayer 



15/17 



signal to the phone and then displaying the message. Preferably by clicking on 
an icon or option near the user's data the user can than automatically enter for 
example chat mode with the person or initiate an automatic call to the person 
(without knowing the actual number at this stage). This can be used also for 
example whenever someone highly compatible enters within Bluetooth range 
from him/her or is close according to the information from the cells, or for 
example from the GPS, and then preferably the user is also given data that can 
help him/lier locate the person for example by showing the appearance data 
that are available, and/or giving the user more precise location data, such as for 
example pointing him/her to the direction and distance of the potential date, 
and/or giving for example street information, as explained above in clause 1 1 
(However, this is intended mainly for locating someone on the street, not for 
giving the exact address where he/she lives, so that the actual address from the 
potential date's questionnaire is preferably not given to the user even if 
available. Also, preferably users can request to block this feature so that 
potential dates that get their data will not be given pointers to their exact 
location) . Of course, various combinations of the above variations are also 
possible. 

16. Since practice shows that most people in computer dating services, including 
Online services, don't like to send their pictures but prefer to search dates that 
have pictures, preferably the system allows users to use a systematic data pool 
of pictures (which can be for example a taxonomy or hierarchy), preferably 
real photographs (for example hundreds of pictures of male faces, hundreds of 
pictures of female faces, and similar separate sets for body shapes) and to 
choose at least the face that is most similar to the way they look and preferably 
also the body shape that is most similar to the way they look, and preferably 
also mark similarly the kinds of appearances they would most like in their ideal 
date (for example by marking the pictures that they most like, preferably with 
the ability to indicate the level of liking on a scale). Preferably there are more 
faces to choose from than body shapes, since there is much more possible 
variation in faces. Another possible variation is to use preferably carefiiUy 
drawn images, which makes it easier to control more systematically various 
variables (or for example some photos and some drawings, etc.). Another 
possible variation is to make the choices (for example both for self description 
and for description of the ideal date) more modular than just body and faces, 
thus allowing the users to create more combinations. This is also important 
because it is very difficult to properly cover appearance, which is wholistic, by 
a few analytic questions. Preferably when this additional info is available it is 
used for the scoring of compatibility in appearance in addition to the normal 
textual question about appearance. Preferably when there is no direct match 
between marked self image and marked preferences in these images, the 
system takes into account a also the distance between the preferred and the 
actual image, based on the systematic classification of the images according to 
various variables. When a potential date's data is displayed, and when no real 
picture of the date is available, preferably this "approximate image" is 
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displayed instead. This has the additional advantage of saving bandwidth and 
saving space and load on the server, because for approximate images it is 
sufficient to transfer just some numerical codes. Preferably these pictures or 
images are small and are downloaded automatically as part of the client, so that 
viewing them does not overload the server. (Preferably they can also be 
automatically updated sometimes by the server when needed, like the other 
updates described in clause 7). For efficiency reasons, preferably when letting 
the user mark choices many images are displayed on the screen together, as 
long as they don't become too small to discern the important details. Another 
possible variation is that the user is preferably asked to make choices in a tree- 
like manner - for example choose first between a number of images and then 
refine the choices based on the previous choices. When the choice is made for 
self description preferably the user can choose only one answer on each step in 
the tree, and when the choices are made for the desired date preferably the user 
can mark multiple options at least in some of the stages. (Preferably at least the 
top of the decision making tree may contain textual descriptions and/or 

J explanations instead or in addition to images). Another possible variation is 

that preferably the user first fills the textual questions about appearance and 
then the system displays the graphic choices already based on the textual 
information about the self description and about the desired date. This narrows 
down the choices that have to be made and the number of images that actually 
need to be displayed and thus increases the efficiency. This way even if 
thousands of images are available to choose fi-om, the choices can still be made 
very quickly and very efficiently. Another possible variation is that this is used 
even with users that do send a photo, in addition to the photo, because of the 
above described advantages in comparison to just using photos. Of course, 
various combinations of the above variations are also possible. Another 

"v possible variation is to use these approximate images (and/or real photos when 

available) to create Virtual Reality environments where clients can "meet". 

18. Another possible variation is to use the data from the compatibility 
questionnaires filled by the users to create ''group compatibility" - which 
means creating a group of compatible people. One of the possible ways to 
accomplish this is for example by running the following algorithm: 1. First one 
or more individual is chosen that fulfill some required criteria. 2. Assuming 
that for example one female was chosen, the computer now finds one or more 
males most compatible with her (preferably by reciprocal compatibility) and 
adds them to the group (This finding of most compatible dates can be done on 
the fly or by using for example the previouslv generated list of most 
compatible dates that each person has). 3. For each of the males last added to 
the group the computer now finds one or more of the females most compatible 
with them (on condition that they are not already in the group) and adds them 
also to the group. 4. The computer now finds one or more of the most 
compatible dates for each of the recently added females, then for the newly 
added males, and so on. until the required group size has been reached. When 
findmg the most compatible date or dates for each newly added member, the 
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computer can either take each time the next most compatible date for that 
person, or take into consideration for example also how compatible the new 
candidate is with the other members of the opposite sex that are already in the 
group (for example on average). This is useful for example for creating 
meetings or parties or virtual meetings for groups of high group compatibility. 



